Modern Java in Action: The Synchronous Bottleneck: Why Async Matters

In distributed systems, the Synchronous Bottleneck is a silent killer of performance. When you invoke a Synchronous API, your calling thread is effectively held hostage, suspended in an idle state until the method computes a result. In a world of 16-core CPUs, your application might spend 99% of its time doing absolutely nothing but waiting.

The Reactive Manifesto

To build modern software, we must follow the Reactive Manifesto, shifting toward systems that are:

Responsive: Fast and consistent response times.
Resilient: Staying responsive despite failures via decoupling.
Elastic: Scaling resources based on demand.

An Asynchronous API solves this by returning control immediately, delegating tasks to background threads. This nonblocking behavior is the prerequisite for high-throughput, elastic systems.

TERMINAL bash — 80x24

> Ready. Click "Run" to execute.

QUESTION 1

How is a Synchronous API best defined in the context of thread execution?

The method returns immediately and uses a callback.

The caller waits while the method computes, continuing only when a value returns.

The method runs on a separate daemon thread automatically.

It is a prerequisite for Reactive systems.

QUESTION 2

What is the primary benefit of an Asynchronous API?

It eliminates the need for any threads.

It returns control to the caller before computation is complete (nonblocking).

It makes calculations faster on a single core.

It guarantees that no exceptions will occur.

QUESTION 3

Which Pillar of the Reactive Manifesto emphasizes remaining responsive despite partial failures?

Elasticity

Resiliency

Responsive

Synchronicity

QUESTION 4

If querying 10 shops sequentially takes 10s, how long would it roughly take asynchronously with sufficient threads?

10 seconds

1 second (the time of the slowest single call)

5 seconds

0 seconds

QUESTION 5

What does the 'Elastic' pillar of the Reactive Manifesto describe?

The ability to recover from a crash.

Reacting to changes in input rate by scaling resources.

Using the same thread for all computations.

Ensuring response times are exactly 1ms.

Case Study: The Best-Price-Finder Challenge

Optimizing Synchronous Legacy Code

You've been asked to develop a best-price-finder application, and all the shops you have to query provide only the same synchronous API implemented as shown at the beginning of section 16.2. ... As you may have expected, the time that the findPrices method takes to run is a few milliseconds longer than 4 seconds, because the four shops are queried sequentially and blocking one after the other, and each shop takes 1 second to calculate the price of the requested product.

1. Implement a method `findPrices` that returns a List of strings synchronously, where each string contains the name of the shop and the price.

Solution:
java public List<String> findPrices(String product) { return shops.stream() .map(shop -> String.format("%s price is %.2f", shop.getName(), shop.getPrice(product))) .collect(toList()); }

2. Big Questions: How to make your code nonblocking when you're a consumer of a synchronous API?

Solution:
To make the code nonblocking, you must wrap the synchronous calls in a `CompletableFuture.supplyAsync`. However, to avoid stream laziness making it sequential again, you must first collect all the CompletableFutures into a list to trigger execution, and then join them in a second step.